home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0348.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  2.5 KB  |  57 lines
  1. > > Ehhmmm... this is probably a very stupied question, but...
  2. > > Can't you make a mod player on the FPU in some way?? :-)
  3. > 
  4. > You could, but it would be so slow you would need at least 120Mhz FPU to make any
  5. > significant savings in CPU time. Maybe even that's an underestimation.
  6. > 
  7. > The FPU is not a separate processor - it just equips the CPU with a bunch of new
  8. > instructions. The CPU still has to execute them, and still has to wait for the
  9. > results - even if the two devices can overlap their work to some degree.
  10. > 
  11. > Treating the FPU as an 'extra' processor will not solve any problems for us.
  12.  
  13. That said it all.
  14.  
  15. > > I have never heard about anyone doing it, but 96-bit accuracy sound good for the sound quality.
  16. > > If you can't do a modplayer, maybe a vector synthesizer? Sounds like a cool and wonderful crazy
  17. > > project to me to implemetn some kind og music on the FPU. I understand that it can't probably be
  18. > > sued for anything, but... :-))
  19. > 
  20. > FPU is very good for non-realtime audio (synthesis & processing), but that's about
  21. > it. You need a DSP or some stand-in equivalent (CPU) to do anything in realtime.
  22.  
  23. Hmm.. I wonder why some programes (like screensavers) needs a FPU. Do they calculate something
  24. in realtime using the FPU or only sometings in the start up? 
  25.  
  26. > The FPU can do nothing. It's not a processor - it just adds a bunch of new opcodes
  27. > to the CPU, and takes over execution of these opcodes when the CPU hits them. You
  28. > can't give the FPU a job and let it get on with it. It has no execution pipeline of
  29. > it's own.
  30.  
  31. What a piece of junk! ;-)
  32.  
  33. > > As I said, this is probably a _very_ stupied question.... :-)
  34. >  
  35. > Well, you know the facts now! :)
  36.  
  37. And telling from the facts it was, eh.. a very stupied question (to say atleast). :-)
  38.  
  39. > > It would certainly make the collision detection EASIER to write, but it's worth the
  40. > > little extra effort to make it run on every machine. The FPU becomes really useful
  41. > > when developing the routines and testing them - but it's best avoided after that
  42. > > stage.
  43. > 
  44. > > Maybe you could have two modes. One with high accuracy for those with a FPU and another
  45. > > one for those without? :-)
  46. > 
  47. > I have an even better idea - just do one for the CPU! That way everybody gets the
  48. > same version, and they are all fast, and they are all accurate. Forget the FPU - 
  49. > It's of no practical use to us beyond the development & testing process.
  50.  
  51. Wow, that wa san idea... lets stick to it (BTW. I havn't got any FPU in my bird anyway..). 
  52.  
  53. :-)
  54.  
  55. //Magnus Kollberg
  56.  
  57.